Systems On a Chip (SOCs) have extreme, complex clocking structures such that signals dovetail on time reliably. Multiple nodes coordinate their activity and the coordination of clocking for all of the nodes is a problem. Processors have increased in speed and have diminished in size thereby leading to the use of more processors and consequently an increase in the number of clocks. However, clocks vary in precision due to due to heat, oscillator capabilities, etc. These and other factors result in clock drift. Clocks may also vary as a result of internal bias, i.e., clock skew. Furthermore, the Time of Flight (ToF) from node to node is approximately one foot per nanosecond. Due to ToF restrictions alone may affect clock signals ability to traverse dies of certain geometries at particular frequency ranges. However, service requirements depend upon accuracy of timing, e.g., timeliness of responses, resilience to faults, etc.
The dependency on multiple clocks causes more heat, and leads to increased entropy. more network communication infrastructure and more wiring, as well as additional routing resources for worst case conditions. The dependency on multiple clocks also may cause increased cost for production, cooling and software. Processing for clock synchronization may be account for 20% to 30% of total processing.
Distributed processing has been used to increase computer processing. However, increasing the density of the processing on the chip still cannot resolve timing and synchronization issues. Synchronizing clocks on all nodes on a SOC is difficult to achieve due the challenge of aligning thousands of clock signals, hence less than optimal bandwidth is provided as one third or more of computational resources are used to manage synchronicity. Calculations have been used to attempt to align clock skews and clock drift, the time of flight, clock drift and skew and placing these timing signals within an acceptable error range such that data and processor loads finish within an acceptable range. In addition, synchronization messages have been broadcast to determine an approximate a master clock.
To establish and maintain a common time base, a synchronization primitive has also been tried. However, padding and worst case clock error constraint incur a performance hit. Further, the problems encountered are further compounded as more clocks and more loads are added to the system, whereby a solution uses either more hardware or more software (usually both). Clock error scaling presents a problem due to the number of nodes, the physical distance, and the use of inhomogeneous device types and communication channels.